Software libraries have traditionally been used to encapsulate sub- or partial-programs prior to full application deployment. A software library provides a set of well-defined Application Program Interfaces (APIs), and comprises an implementation of specific functionality, invokable via those APIs. The library is packaged as a single entity.
The library model has a number of benefits. These include the ability to permit multi-party development, since a library separates the originating software party from the integrating software party, encapsulating the partially complete software in a reusable module. Encapsulation of software in modular libraries also encourages the re-use of code. And, although not a specific design requirement, libraries also permit a degree of source code protection as they are pre-compiled, usually object form, modules. However, a determined attacker may be able to reverse-engineer the executables that are created from the library.
The software library model has had little innovation since the 1970's and 80's. Traditional software libraries typically contain object-code, which is very close to executable instructions, apart from a few higher-level concepts such as relocatable symbols. The nature of such object-code necessitates that the library creator statically determine, at library creation-time, most executable aspects of the code, including security and performance attributes, before distribution to the end-user. Additional tooling, in the form of a linker or dynamic loader, makes it possible to build an executable application which incorporates the functionality of the software library by relocating the object-code into the address space of the application executable (see e.g. J. Levine, Linkers and Loaders, Morgan Kaufmann Publishers, 2000).
It is therefore desirable to provide a library format that allows the bulk creation of diverse binaries that are resistant to reverse-engineering.